IBIS Macromodel Task Group

Meeting date: 22 September 2015

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                   Xingdong Dai
                            * Bob Miller
Cadence Design Systems:       Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC                         David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
IBM                           Steve Parker
Intel:                        Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                            * Todd Westerhoff
                            * Mike LaBonte
Synopsys                      Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong

(Note: Agilent has changed to Keysight)

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- None

--------------------------
Call for patent disclosure:

- None
-------------
Review of ARs:

- Arpad to update the draft of the Info, Out, InOut BIRD.
  - Done (revision #12 posted on the ATM website).

- Mike L. to add a ver6_1_known_issues.txt to the 6.1 spec folder and add the
  issue Arpad discovered ("General Reserved Parameters" section number).
  - Done.

-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Mike L: Motion to approve the minutes.
- Todd: Second.
- Arpad: Anyone opposed?  [none]

-------------
New Discussion:
  
Item #6: Info, Out, InOut BIRD draft.
- Arpad: [sharing and reviewing the newly posted revision #12]
  - Name of the parameter changed to NonStandardParams.
  - New "Other Notes" section.
    - Other Notes: A non-standard Model_Specific parameter may require action
      from the user or the EDA tool that is not described in the IBIS
      specification.
- Bob R: Add the Info, Out, InOut to the Other Notes text to fully describe
         what parameters' Usage(s) might be non-standard.
- Walter: Why doesn't it include Usage In?
- Arpad: In goes from the AMI file to the model.
- Walter: That's not necessarily true.  It is also available for use by the
          EDA tool.
- Todd: This is a voluntary declaration of something as non-standard.
  - Therefore, we shouldn't assume the degree of non-standard-ness.
- Arpad: Okay, then this BIRD is open to all Usage(s).
- Bob R: I prefer NonSpecified to NonStandard.  A parameter could comply with
          the specification but expect the tool or user to modify the
          parameter in a non-specified way.
- Radek: The issue is only whether any special action should be taken by the
         tool based on the value of such a parameter.
- Bob R: This is a specification, it may become a standard but it's not a
         standard yet.
  - It's really a non-specified action we are talking about.
- Mike L: If we're making an important distinction, any one of our
          specifications could become standards.
- Radek: The only things specified are Reserved Parameters.
  - Anything in the Model Specific section is not specified by the
    specification.
  - So by this definition everything in Model Specific would be unspecified.
  - I think NonStandard is closer to the meaning we want.
- Bob M: I think the crux of this issue is also with the Other Notes statement.
  - I think it should not include the words "from the user".
  - Model vendors may have plenty of parameters that require the user to set
    them appropriately in order to get useful results from the model.
  - The key is whether the EDA tool directly interacts with the parameter.
  - For example, a "tuning mode" parameter that allows the user to select
    the value does not require special handling.
- Discussion:  What is NonStandard (or NonSpecified)?
  Bob R.'s initial comments about nonstandard vs. nonspecific led to a
  discussion that revealed a more fundamental difference of opinion on this
  BIRD.  Bob M.'s example (Model Specific "tuning" parameter of Usage In,
  Format Table, Type String, from which the user would select a value) served
  to highlight the difference.  Bob M., Radek, John, Todd, and Curtis all
  supported the interpretation that such a parameter would not need to be
  listed in the new NonStandardParams.  It was an acceptable use of a Model
  Specific parameter and would classify as "normal processing."  Since only
  the user was making the selection, and the EDA too was not doing anything
  with the parameter on its own, nothing was NonStandard.  Any EDA tool should
  be able to present the user with the list of choices.  Bob R. contended that
  such a parameter should be listed in the new NonStandardParams because its
  behavior was not defined in the specification.  Others (see Radek above)
  felt that this interpretation would then apply to all Model Specific
  parameters, rendering the new NonStandardParams meaningless.  Throughout the
  discussion Arpad tracked various proposed changes in the language of the BIRD
  for use in a future revision.
- Discussion: Using Reserved Parameters.
  Todd brought up a suggestion he had previously made.  One might list the non-
  standard params under Reserved Parameters (since they require some special
  handling that needs to be defined eventually), but also list them under the
  new NonStandardParams so that the parser would know not to issue errors when
  it found Reserved Params it didn't recognize.  This would let the user know
  what params expected special handling from the EDA tool (those in Reserved),
  but which ones weren't defined in the spec (NonStandadParams).  Bob R. again
  opposed this concept.  Arpad pointed out that the current definition of 
  Reserved Parameters was that it included only things fully defined by the
  spec.
- Discussion: Tstone models as an example.
  The tstone models were brought up as an example of special handling.  The
  tstone parameter would need to be listed in the NonStandardParams.  The
  tstone models also contain documentation listing workarounds the user might
  employ when using a tool that does not support the non-standard tstone (for
  example, manually including the touchstone model directly in the circuit).
  This was noted as a good thing to do in the case of non-standard parameters.
- Bob R: Anyone can use the name 'tstone.'
- Radek: That's a good example.
  - You may have a tstone parameter that should be completely ignored by the
    EDA tool.  It may be used by the .dll to find the file and do something
    with the data, for example.
  - Therefore this NonStandardParams that lists those params that actually
    require special handling by the EDA tool is useful in differentiating
    between the two cases.
- Bob M: That's the first time I've heard a really good reason for having
         a table of the non-standard parameters.
  - A model may use the same name in Model Specific quite by accident, but if
    it's present in the table the EDA tool knows something odd is going on
    with it.
- Mike L: It's important to make sure that model makers will have a consistent
          understanding of whether a parameter falls under this BIRD or not.
- Arpad: Thank you all for joining.

AR: Arpad to work on next revision based on language changes proposed during
    the discussion.

-------------
Next meeting: 29 September 2015 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
